This is a standard Jms 1.0.2b and 1.1 connector. This connector exposes all features defined in the 1.0.2b/1.1 Specification.

The javadoc for this transport provider can be found here. And the Source Xref can be found here.

Using Topics, Queues or both

When specifying a destination name and JndiDestinations are not being used the default destination created is a Queue.
For example the Jms endpoint

jms://my.destination

will manifest itself as a Jms Queue called my.destination. To make this a topic you must prepend the destination name with topic:-

jms://topic:my.destination

If you are using a Jms 1.1 compliant server you can use the same JmsConnector for queues and topics. If you are using a Jms 1.0.2b server and you want to use both queues and topics in your Mule configuration, you will need to create 2 JmsConnectors; one with a jndiConnectionfactory that references a QueueConnectionFactory and the other that references a TopicConnectionfactory. Then each Jms endpoint will need to reference the correct connector depending on whether the destination is a topic or a queue. To specify the conector on a jms endpoint you need to add the connector parameter -

jms://my.destination?connector=jmsQueueConnector

or

jms://topic:my.destination?connector=jmsTopicConnector

Specifying Credentials

Client connections may need to supply a username and password when creating a connection. This information can be specified on the URI.

jms://ross:[email protected]?createConnector=ALWAYS

or

jms://ross:secret@topic:my.destination?createConnector=ALWAYS

Note that the 'createConnector' param is set to 'ALWAYS'. This ensures that a new connection is made with the user credentials. When creating JmsConnectors more information is is needed such as ConnectionFactory Jndi details. This can be set as parameters on the URI, but this can get difficult to manage not to mention messy. It is possible to set default properties for connectors when they are created. For more information see this Jms cookBook entry.

See Mule Endpoint URIs for more general information about configuring endpoint URIs.

Jms Selectors

You can set a Jms selector as a filter on an endpoint. The JmsSelectorFilter simply sets the filter expression on the consumer.

<endpoint address="jms://important.queue">
    <filter expression="JMSPriority=9"
        className="org.mule.providers.jms.filters.JmsSelectorFilter">
</endpoint>

Below is the old way of setting a Jms selector on an endpoint, but is still supported for backward compatibility. Also, setting the selector as a URI param can still be useful.

To set it on an explicitly configured endpoint as a property of that endpoint -

<endpoint address="jms://important.queue">
    <properties>
        <property name="selector" value="JMSPriority=9"/>
    </properties>
</endpoint>

Or to specify the same provider using a uri -

jms://important.queue?selector=JMSPriority=9

Durable Subscribers

Durable subscribers can be used by setting the durable property on the JmsConnector, this tells it to make all topic subscribers durable. Only Topic subscriptions can be durable. When a durable subcriptions a durableName is needed by the Jms server to identfy this subscriber. By default, Mule generates a durableName in the following form -

mule.<connector name>.<topic name>

However, if you want to set the durableName yourself, you can do so on the endpoint by setting the durableName property.

<endpoint address="jms://topic:durable.topic">
    <properties>
        <property name="durableName" value="myDurableSubscription"/>
    </properties>
</endpoint>

or the equivilent  -

jms://topic:durable.topic?durableName=myDurableSubscription

You can also specify certain endpoints to be durable while others are not by setting the durable property on the JmsConnector to false and then setting the durable property on the individual endpoints.

<endpoint address="jms://topic:durable.topic">
    <properties>
        <property name="durable" value="true"/>
    </properties>
</endpoint>

or the equivilent  -

jms://topic:durable.topic?durable=true

Overloading Jms behaviour

Some Jms servers require a different sequence of calls when creating Jms resources, for example Oracle's Advanced Queuingrequires that the connection is started before listeners can be registered. In this scenario the user can overload the JmsSupport class to customise the way Jms resources are initialised. Configuring this customisation requires that you tell the JmsConnector to use a custom JmsSupport class.

<connector name=jmsConnector" className="org.mule.providers.jms.JmsConnector">
    <properties>
        <property-factory name="jmsSupport" value="org.foo.jms.CustomJmsSupport"/>
        ...
    </properties>
</connector>

For more information about configuring different Jms Servers go here.
For more information about configuring providers go here.

Jms Transformers

Transformers for the JMS provider can be found at org.mule.providers.jms.transformers

Jms Header Properties

When the message is received and transformed all the message properties are still available via the UMOMessage object. To access sandard Jms properties such as JMSCorrelationID and JMSRedelivered simply use the property name i.e.

String corrId = (String)umoMessage.getProperty("JMSCorrelationID");

boolean redelivered = umoMessage.getBooleanProperty("JMSRedelivered");

any custom header properties on the message can be accessed the same way.